The concepts of software-defined networking (SDN) and NFV have gained severe interest during the past few years as they enable creating software-based networks that are more programmable, scalable, and affordable than traditional networks based on more or less specialized hardware. NFV is basically about virtualizing tasks previously done in hardware by translating various networking tasks as load balancing, routing, and intrusion detection and prevention into software executable in a cloud on virtual machines using commodity hardware, whereas SDN is, in turn, about translating the associated control plane for managing virtualized network functions (VNF) into software.
ETSI (European Telecommunications Standards Institute) has established standards for designing and implementing NFV systems. For example, ETSI GS NFV-MAN 001 NFV; Management and Orchestration, V1.1.1 (2014-12), incorporated herein by reference in its entirety, describes the management and orchestration framework required for the provisioning of VNFs and related operations.
In traditional networks, network function (NF) implementations are usually tightly coupled with the infrastructure they run on, while NFV decouples software implementations of NF's from the computation, storage, and networking resources used for their realization. The virtualisation environment insulates the NFs from those resources through a virtualisation layer.
FIG. 2 represents, at 200, Network Functions Virtualisation Management and Orchestration (NFV-MANO) architectural framework as defined by the ETSI for managing the resources of NFVI (NFV Infrastructure) and orchestrating their allocation as needed by various network services (NS) and VNFs 210 used to implement them. One or more VNFs and/or Physical Network Functions (PNFs) may be connected to realize an NS. The framework includes computing, networking, storage, and virtual machine (VM) resources. The VNF Manager (VNFM) 208 manages the life cycles of VNFs. In addition, the NFV Orchestrator (NFVO) 204 manages the life cycles of network services utilizing the VNFs.
In more detail, VIM (Virtualized Infrastructure Manager) 212 takes care of managing NFVI resources in its target domain (there may be many in the overall NFV architecture) by creating, maintaining and deleting virtual machines (VM) from available physical resources, creating and maintaining virtual links, virtual networks, sub-nets, and ports to support the management of VNFFGs (VNF Forwarding Graph, chaining VNFs to establish desired end-to-end services), maintaining software images for VNFs 210, collecting performance and fault data, and managing catalogs of virtualized resources, resource configurations (e.g. virtual CPU configurations, types of network connectivity, etc.) or templates, for example.
NFVI 214 encompasses the actual hardware (e.g. compute, storage, and networking) and software (e.g. hypervisors) components that together provide the infrastructure resources where VNFs 210 are ultimately deployed for execution. The NFVI 214 may also include partially virtualised NFs. Examples of such partially virtualised network functions are related to “white box” switches, hardware load balancers, DSL Access Multiplexers (DSLAMs), Broadband Remote Access Server (BRAS), Wi-Fi access points, CPEs, etc., for which a certain part of the functionality is virtualised and may thus be in the scope of NFV-MANO 200 while other parts can be built in silicon (PNF, physical network function) due to e.g. physical constraints (e.g. digital interfaces to analogue physical channels) or vendor design choices.
Element Management (EM) 206 is responsible for the FCAPS (Fault, Configuration, Accounting, Performance and Security management) for a VNF 210. The EM 206 may collaborate with a VNF Manager (VNFM) 208 to perform those functions that require exchange of information regarding the NFVI resources associated with the VNF 210.
The VNFM 208 manages the life cycle of VNFs 210 by setting them up, maintaining and ultimately terminating them. It 208 also takes care of FCAPs of VNFs for the virtual part. Yet, it 208 may scale VNFs up or down. A single VNFM 208 may manage multiple VNFs or just one. For example, when a VNF is to be instantiated (or scaled), the VNFM consults a corresponding VNF Descriptor (VNFD), to perform the following:                allocate and configure NFVI resources (compute, storage and network resources),        load or install the software components of the VNF; for example, using a repository of software images provided in a corresponding VNF package,        set up virtualized network connectivity between the VNF components and to other network elements, and        connect the VNF to the operations support system (OSS) layer and manage and monitor it during its lifetime.        
OSS/BSS 202 refers to the combination of the operator's other operations and e.g. business support functions that are not otherwise explicitly captured in the shown architectural framework 200, but are expected to have information exchanges therewith. OSS/BSS functions 202 may provide management and orchestration of legacy systems and may have full end to end visibility of services provided by legacy network functions in an operator's network.
NFV Orchestrator (NFVO) 204 handles the automatic management of network services' life cycle and of global NFV Infrastructure resources potentially across multiple data centers. The NFVO 204 may connect, or chain together, different functions to create end-to-end services in the NFV environment. In addition, the NFV Orchestrator manages NFV infrastructures e.g. among multiple VIMs 212 and coordinates resource requests. In practice, the NFVO 204 generates, maintains and deletes network services of one or more VNFs through communication with VNFM 208 and VIM 212. An end-to-end service of multiple VNFs from one or more vendors may be thereby created by communicating with the respective VNFMs 208.
The NFVO 204 on-boards various descriptors. For example, so-called NSDs, VNFFGDs, and VLDs, which are described in more detail hereinbelow, are “on-boarded” into the NS Catalog 204a, whereas VNFD is on-boarded in the VNF Catalog 204b as part of a VNF Package including also e.g. software images. Also PNFDs (physical network function descriptor) can be on-boarded.
Network Services (NS) Catalog 204a indeed refers to a repository of all on-boarded Network Services, enabling the creation and management of the NS deployment templates with reference to e.g. a Network Service Descriptor (NSD) including a plurality of information elements that enable the NFVO 204 to instantiate (deploy) the concerned NS formed by VNFFG(s), VNF(s), PNF(s), and/or VL(s). The information elements of the descriptor contain references other descriptors, which describe components that are part of that NS, including e.g. VNFFGD(s), VNFD(s), possible PNFD(s) and VLD(s) utilized by the NS.
A VNFFGD (VNFG Forwarding Graph Descriptor) is a deployment template which describes a topology (VNFFG) of the NS, or a portion of the NS, by referencing VNFs and PNFs and Virtual Links that connect them, i.e. it defines a service chain of VNFs to determine the service. VNFs contain connection points by which VNFs may be connected together by establishing virtual links (VL) therebetween. The VNFFG defined by the VNFFG contains a Network Forwarding Path (NFP) element that defines a sequence of actions that are to be performed, for example, by a collection of VNFs, to provide the requested service.
A Virtual Link Descriptor (VLD) describes in more detail e.g. the resource requirements that are needed for a link between VNFs, PNFs and endpoints of the NS, which could be met by various link options that are available in the NFVI).
On-boarding of an NS thus incorporates registering the NS, based on the obtained service specification data, in the catalog 204a. For example, instantiation of an NS is described by a related VNFFG, which defines the set of network functions that are required to execute the requested service.
A VNFD is a deployment template which describes a VNF in terms of its deployment and operational behaviour requirements. It is used e.g. by the VNFM in the process of VNF instantiation and life cycle management of a VNF instance. The information provided in the VNFD is also used by the NFVO 204 to manage and orchestrate Network Services and virtualised resources on the NFVI. The VNFD also contains connectivity, interface and KPIs requirement information. As mentioned above, the VNFD is on-boarded in VNF Catalog 204b, as part of a VNF Package.
VNF Catalog 204b represents the repository of (all) on-boarded VNFs in terms of VNF Packages, thus supporting the creation and management of the VNF Package (including e.g. VNF Descriptor (VNFD), software images, manifest files, etc.) via interface operations provided by the NFVO 204. Both NFVO 204 and VNFM 208 can query the VNF Catalog 204b for finding and retrieving a VNFD, to support different operations (e.g. validation or checking instantiation feasibility).
FIG. 3 illustrates the structure of one example of an end-to-end service incorporating at least one network service, NS 304, wherein the related VNFFG(s) 308 defined by corresponding VNFFGD(s) describe a topology of the NS or at least a portion of the NS, by referencing VNFs 210, possible PNFs 302 and Virtual Links 310 that connect them between the end points 306.
To construct a desired end-to-end, E2E, service, multiple Network Services can be combined with reference to combining e.g. mobile radio access network service with mobile core network service. For clarity reasons, only a single NS has been depicted in the figure but there could thus be several interconnected, even nested, network services in a common service chain to establish the desired E2E service.
Reverting to FIG. 2, NFV Instances repository 204c may hold information of all VNF instances and Network Service instances deployed (realized). Each VNF instance is represented by a VNF record, and each NS instance is represented by an NS record. Those records are updated during the lifecycle of the respective instances, reflecting changes resulting from execution of NS lifecycle management operations and/or VNF lifecycle management operations. This supports NFVO's and VNFM's responsibilities in maintaining the integrity and visibility of the NS instances, respectively VNF instances, and the relationship between them.
NFVI Resources repository 204d may hold information about available/reserved/allocated NFVI resources as abstracted by the VIM across operator's Infrastructure Domains, thus supporting information useful for resources reservation, allocation and monitoring purposes. As such, the NFVI Resources repository plays an important role in supporting NFVO's Resource Orchestration and governance role, by allowing NFVI reserved/allocated resources to be tracked against the NS and VNF instances associated with those resources (e.g. number of VMs used by a certain VNF instance at any time during its lifecycle).
Especially when provision of more complex network services or E2E-services, such as hybrid services employing services of legacy (traditional, non-virtualized) and virtualized nature, is to be supported by a selected MANO framework and e.g. orchestrator thereof, situations may easily occur where service specifications are to be imported and on-boarded in a catalog from various different sources.
In this context, with reference to e.g. NSDs, i.e. NS descriptors indicative of NS capabilities such as policies, resources needed, dependencies on other services, functions etc. as discussed hereinbefore, such NSDs or alternative service descriptions or specifications could be obtained from different sources, written in different formats and relying upon different standards adopting e.g. different naming conventions with reference to TOSCA (Topology and Orchestration Specification for Cloud Applications) and NETCONF/YANG (Network Configuration Protocol) based solutions, representing examples of mutually different standards utilized for setting up and configuring as well as for orchestrating virtual/physical networks.
As a practical example, when different service descriptions are obtained from multiple sources and on-boarded (registered) in a common catalog, they may follow mutually very different naming convention as to related transactions, i.e. behaviours of a catalog item (actions that can be performed with catalog items or parameters), such as life cycle events, or life cycle “operations”.
E.g. in one source system a certain life cycle operation could be called ‘DELETE’ while in some other it was called ‘REMOVE’ or ‘TERMINATE’. This versatility is problematic both from the standpoint of managing the catalog itself and controlling the actual deployment and generally life cycle of service instances of related services based thereon, not least having regard to constructing E2E services from the services or generally components provided by a plurality of different vendors (sources).